markdown-itのrenderer ruleの内部仕様をどのLLMも間違って学習していたが、DeepWikiのchatだけは正しいコードを出してくれた
現状のまとめ
AIの持ってる知識が間違っている
dead.icon claude code
dead.icon Gemini 2.5 pro
既存のAIコーディングエージェントに現実を理解させる令和最新版仕様書の生成には、まだ成功できていない
dead.icon Gemini 2.5 Deep Research
試した中では唯一、DeepWikiが良さそうshokai.icon
chatにコード書かせたら正しい認識を持っている事が確認できた
まだ試してないが、芽のありそうな方法
DeepWikiに最新仕様書を生成させてclaude codeに作業させる
claude codeにDeepWikiそのものを読ませる
claude codeにDeepWikiのchatとMCPで会話させる
ペーストされたテキスト内のmarkdownの装飾を解除するで使っているmarkdown-itの扱いに困った
markdownのparserである
parseしてtokenの配列を作って、HTMLに変換できる
token配列からHTMLへの変換の間にレンダリングオプションを仕込める
超メジャーなnpmではない
歴史があって安定しているので採用したshokai.icon
weekly download 700万あるので準メジャーといっていい
Claude CodeやGemini 2.5 Proでもかなり出力するコードを間違える
大枠では間違っていない
Gemini 2.5 Proはオプションの意味を実際と逆だと勘違いしている
html: false
機能: Markdownソース内に書かれた生のHTMLタグ（例: <b>, <div> など）をどのように扱うかを制御します。
false の場合: ソース内のHTMLタグは無視されるか、無効化されます（厳密な動作はレンダリングルールによりますが、基本的にはHTMLタグとして機能させません）。セキュリティ上の理由や、意図しないHTMLが出力されるのを防ぐために使われます。
true の場合: ソース内のHTMLタグがそのまま出力されます。
逆なんだよなあ。falseにするとHTMLがそのまま出力されるshokai.icon
出力されるtoken配列の仕様、というか順序を勘違いしている
ざっと見た感じtoken配列の順序がドキュメント化されてないから、サンプルコード等から推測して実装しているのではないか？
明文化されていない仕様をコーディングさせている状況なのかも
AIが完全に使い方を知らない
解決案
ドキュメントの読み方を教えて、ライブラリの仕様を調べさせ、それから実装させる
超雑で作りかけのライブラリ更新プルリクをshokaiが重視している観点でDevinにレビューさせて、リリースノートの確認とアプリ側のコードの修正もやってもらうのように
claude codeのような手元で動いて小回りの効く環境でやりたいshokai.icon
Devinでやった経験はあるが
最近claude codeもfetch toolが動くようになったのでリモートのドキュメント読んで仕様調べれるだろうけど
なんとなくコンテキスト一杯になってすぐ苦しくなりそうなんだよな
sessionリセット毎にドキュメント読ませるのも
自力でトライアルアンドエラーを回させて、AIが想定してる仕様と実際の差を調べさせる
単体テストを回せるようにしてAIエージェントが無限に自力でリトライできる箱庭を作るのが重要そうのパターンに入れる
AIにmarkdown→ブラケティング変換の全仕様を一気に生成させるのはうまくいかなそう
今度はそれをまとめて満たす仕様を一気に実装しようとして、沼にはまるだろう
最低限のtestを書いて、1つずつtest追加と実装修正を繰り返すのが良いだろう
めんどくさいなshokai.icon
足りない部分の仕様をGemini Deep Researchで調べて、仕様書作るのがいいかも
code:プロンプト
https://www.npmjs.com/package/markdown-it の仕様を調べて、AIコーディングエージェントがプログラミング時に参照するのに適したドキュメントを作ってください
ライブラリ全体の仕様は不要です。
フォーカスすべきは、renderer rulesと、実際に生成されるtoken配列の順序や、個々のtokenが持つプロパティの仕様です。
## 調べ方
npmjs.comやgithub.comにあるドキュメントと、リポジトリ内にあるコードを読んで理解する
## 調査を依頼する理由
私はmarkdown文字列を入力して、markdownの一部の装飾を解除しつつ、しかし一部の装飾は解除しないような、装飾解除ツールの実装をしようとしています。
それをmarkdown-itのrenderer ruleのカスタマイズで実装したいのですが
この機能のオプションをあなたたちAI(Gemini 2.5 proやclaude sonnet 3.7)が誤って理解している箇所が多い為、再調査が必要だと考えました
いったんこれで行くshokai.icon
追加で、現状のコードと、どんなmarkdownを処理しようとしてるかの例も必要に応じて教える
https://gemini.google.com/u/shokai@notainc.com/app/dfae2341d77e8658
令和最新版API仕様書ができた
markdown-it 詳細仕様 レンダラールールとトークンストリーム.md
一度Deep Researchしてもらった後、「markdownにして」と追加指示する必要があった
というわけで、Deep Researchで作った仕様書を読ませて作業させようと思ったが
20250430-202302.txt by Claude Code.icon
Deep Research中にshokai.iconが自分で調べて大体解決できてしまった
詳細仕様書に基づいてClaude Code.iconが提案してきた修正案も、どれも不要だったので全て却下した
よって私の勝ちですshokai.icon
まだまだAIは人間に勝てない
DevinのDeepWikiを使ったら、markdownの[![altText](imageURL)](externalURL)を外部リンク付き画像にできた
https://deepwiki.com/search/titleurl-title-url-renderer-ru_e1f15948-c37d-4938-b630-19421824aa57
link_openとlink_closeの解釈が正しい
image tokenの理解も正しい
特に次のtokenにhidden属性を付けて表示制御する発想は私には無かった
DeepWikiの出力を元に手動で改良した
https://gyazo.com/29c4bb69f6c8e0d3e2f5339eb204f887
書いたコードそのまま採用したわけではなく、参考にした
しかしDeepWiki以外のコードはどれも根本的に仕様を誤って理解していて、ぜんぜん参考にならなかったので
マイナーなライブラリのコード書かせるなら現状DeepWikiが最適なのかもしれない
DeepWikiの知識をclaude codeに取り込みたいなshokai.icon
手元でやりたい
Devinで新機能を実装するのはちょっと小回りが効かないので